1. Field of the invention
The present invention relates to a mobile node and a home agent for reducing the overhead in tunneled data exchanged therebetween and a method therefor.
2. Description of the Related Art
The Internet Protocol (IP) allows the exchange of packets, or datagrams, between various nodes having IP addresses. A packet sent from a first node towards a second node comprises a header, itself comprising an IP address of the first node as a source address and an IP address of the second node as a destination address, and a useful payload. Traditionally, an IP address identifies, and is linked to, an attachment point of a node within a network. As a mobile node (MN) moves between IP networks, an IP address of a fixed, constant value cannot be used by various network elements to locate and communicate with the MN because distinct the MN has changed from one attachment point to another one. Mobile Internet Protocol version 6 (MIPv6) is a technology for providing a stable identifier, called a home address (HoA) to a mobile node while it is moving between multiple IP networks. This is established by mapping the HoA into a care-of address (CoA) that is representative of a current topological address of the MN. This mapping may be performed either by a home agent (HA), in a bidirectional tunneling mode, or by a correspondent node (CN) in communication with the MN, in a route optimized mode.
FIG. 1 is a prior art representation of a CN 120 in communication with a MN 110 within an IP network 100 using MIPv6 in bidirectional tunneling mode. The bidirectional tunneling mode works by tunneling all traffic from and to the MN 110 through a HA 130. Data sent from, or received at, the MN 110 is intended to, or initiated from, the CN 120. The CN 120 is aware of a HoA of the MN 110, which is an IP address related to a subscription of the MN 110 within a network which is, for that MN 110, its home network. Within the home network, the HA 130 allocates the HoA to the MN 110. When the CN 120 sends a data packet intended to the MN 110, it uses its own IP address as a source address and the HoA of the MN 110 as a destination address. The source and destination addresses are placed in an IP header, which is in turn placed in the data packet.
If the MN 110 is located within its home network, normal IP routing practices ensure that the data packet arrives at the MN 110 by use of its HoA. Specifically, the packet arrives at an ingress router of the home network. The router performs neighbor discovery for the HoA of the MN 110. The MN 110 being present on the link, it responds with its own link layer address and the router delivers the packet to the MN 110. If however the MN 110 is located outside of its home network, visiting a foreign network, as shown in FIG. 1, the foreign network has previously allocated a care-of address (CoA) to the MN 110. The MN 110 has informed the HA 130 of its current CoA in a so-called binding process. The HA 130 keeps binding information linking the HoA and the CoA of the MN 110. When the CN 120 sends the data packet towards the MN 110, on data path 160, it still uses the HoA of the MN 110 as the destination address and its own address as the source address in a first header. As the MN 110 is away, the HA 130 responds to the neighbor discovery with its own link layer address to get the packet from the router. The HA 130 forwards the data packet towards the MN 110 on a tunneled data path 150 by use of the CoA of the MN 110 as a new destination address. The HA 130 supplies its own IP address as a new source address in the packet sent towards the MN 110. The MN 110 needs to know the identity of the CN 120 it is communicating with, because this may, for example, impact an application of the MN 110. Moreover, the MN 110 may eventually send another data packet, for example a response, towards the CN 120. Such a response is sent through the HA 130 on the tunneled data path 150. The MN 110 sends the response intended to the CN 120, using the IP address of the HA 130 as a destination address and its CoA as the source address. The HA 130 forwards the response towards the CN 120 on the data path 160. The IP address of the CN 120 needs to be preserved, and the HA 130 must have a means to recognize the MN 110. The conventional means taken by the HA 130 and by the MN110 to ensure that addressing information of the CN 120 is preserved while packets travel between the HA and the MN on the tunneled data path 150 is by placing the first header, which identifies the HoA of the MN 110 and the CN 120, as a part of an enlarged payload, and by defining a second, additional IP header, to identify the CoA of the MN 110 and the HA 130. The first header is used conventionally between the CN 120 and the HA 130 on the data path 160 while the second header is added between the HA 130 and the MN 110 on the tunneled data path 150. Between the HA 130 and the MN 110, only the second header acts as a standard IP header and the first header is treated as any other payload content.
FIGS. 2a and 2b represent prior art packet formats used between the HA 130 and CN 120 and between the MN 110 and HA 120, respectively. On the data path 160 of FIG. 1, a data packet comprises a first header 210 and a useful payload 220, as shown on FIG. 2a. The first header 210 comprises a source address (SA) 212 equal to the IP address of the CN 120 and a destination address (DA) 214 equal to the HoA of the MN 110. This packet is sent from the CN 120 and, though it is intended for receipt at the MN 110, it can only arrive at the HA 130. In a reverse direction, the SA 212 and the DA 214 would exchange their values. On FIG. 2b, the data packet of FIG. 2a is tunneled into a larger packet, on the tunneled data path 150 of FIG. 1. It can be seen that the first header 210 from the packet as sent from the CN to the HA is added to the payload 220, to actually become a larger payload 240, and that a second header 230 is added. It can be said that the packet format of FIG. 2a is encapsulated within a packet format of FIG. 2b. The second header 230 comprises a SA 232 equal to the IP address of the HA 130, and a DA 234 equal to the CoA of the MN 110. In the reverse direction, the HA 130 may receive a packet formatted by the MN 110 as shown on FIG. 2b, wherein the SA 232 and DA 234 values are exchanged and wherein the SA 212 and the DA 214 values are also exchanged. The HA 130 decapsulates the packet by removing the second header 230 and restoring the first header 210 as the actual, effective header, and forwards the packet with the format of FIG. 2a towards the CN 120.
In the hereinabove described solution for mobility using bidirectional tunneling, each data packets flowing between the MN 110 and the CN 120 is tunneled inside another packet that carries the data between the MN 110 and the HA 130. The size of an IPv6 header is a minimum of 40 bytes. Embedding one header within a packet and adding another header adds significant overhead per packet, and may constitute an inefficient use of transmission resources between the MN 110 and the HA 130. In streaming applications such as in the case of voice over IP (VoIP), the amount of overhead may easily exceed the size of the useful payload. While large overheads may be tolerable in some wired links, the MN 110 frequently is a wireless terminal, connected towards the HA 130 on a wireless link. Even when the MN 110 is not directly connected to the HA 130 on the wireless link, for example when the wireless link exists solely between the MN 130 and a radio base station of a cellular network (not shown), the added overhead caused by tunneling may be deemed inefficient.
Header compression techniques have been used with success to reduce the amount of overhead over wireless links. For example, the well-known Robust Header Compression (ROHC) technique may be used to efficiently reduce the overhead in transmitting IP packets over a wireless link. However, this specific header compression technique can only be applied between two endpoints that terminate an IP connection, because both endpoints need to keep track of any change in the uncompressed headers in order to signal to each other when header changes occur. For example, upon transmission error over a wireless link, header information may change and a mechanism in ROHC may be used to indicate that several upcoming packets will not have any header compression. Otherwise stated, ROHC only applies over one IP hop. For example, ROHC could be applied to reduce the size of the second header 230 of FIG. 2b. But because the HA 130 does not terminate an IP connection between the MN 110 and the CN 120, this IP connection being defined by the first header 210 of FIGS. 2a and 2b, ROHC cannot be applied to reduce the overhead posed by the first header 210.
There is currently no efficient means for reducing the overhead of an encapsulated header in the context of mobile IP communication.